Ο ακραίος προγραμματισμός είναι η πιο δημοφιλής από τις Ευέλικτες Μεθόδους και δημιουργήθηκε στα τέλη της δεκαετίας του '90 από τον Kent Beck. Είναι μία πειθαρχημένη προσέγγιση που υποστηρίζει την ταχύτερη ολοκλήρωση του έργου σε μικρούς επαναληπτικούς κύκλους, επιτρέποντας στους υπεύθυνους ανάπτυξης να ανταποκρίνονται στις μεταβαλλόμενες απαιτήσεις του πελάτη καθ' όλη τη διάρκεια του κύκλου παραγωγής (Beck, 2000). Βασίζεται σε τέσσερεις αρχές και δώδεκα πρακτικές οι οποίες βελτιώνουν και απλοποιούν την ανάπτυξη. Οι τέσσερεις αρχές είναι:
 
Επικοινωνία (communication). Η κοινή αντιμετώπιση των προβλημάτων απαιτεί κοινή κατανόηση μέσω διαπροσωπικής επικοινωνίας.

Απλότητα (simplicity). Η ομάδα εκτελεί πάντα το πιο απλό σχέδιο που πιθανόν θα δουλέψει. Συνεχώς απλοποιεί και βελτιώνει τον κώδικα με αναδόμηση. Όταν ο κώδικας είναι απλός, είναι περισσότερο κατανοητός και καλύτερα τεκμηριωμένος, ενώ τα λάθη είναι πολύ λιγότερα.

Ανατροφοδότηση (feedback). Η τακτική παράδοση λογισμικού στον πελάτη, σχεδόν ανά  εβδομάδα, βοηθά στην συνειδητοποίηση προβλημάτων πριν την ολοκλήρωση του έργου.

Κουράγιο (courage). Το κουράγιο και η καλή ψυχολογία είναι δύο σημαντικοί παράγοντες. Επιτυχημένες ομάδες ανάπτυξης λογισμικού συχνά ενεργούν στην κόψη του ξυραφιού, καθώς πρέπει να εργάζονται πολύ γρήγορα, δίχως όμως να χάνουν τον έλεγχο. Αυτό σημαίνει πως συχνά αποτυγχάνουν. Αν οι προγραμματιστές φοβούνται την αποτυχία, θα ενεργούν πολύ αργά. Σε μια αποτυχία η ομάδα πρέπει να βρίσκει το κουράγιο να συνεχίζει ή να ξεκινά από την αρχή.

Οι αξίες αυτές διαμορφώνουν ένα διαφορετικό πλαίσιο προσέγγισης της ανάπτυξης λογισμικού. Στο πλαίσιο αυτό τα στελέχη της ανάπτυξης επικοινωνούν μεταξύ τους και με τους πελάτες μέσω συνεχούς διαπροσωπικής επικοινωνίας, εξασφαλίζοντας την άμεση ανατροφοδότηση. Χρησιμοποιούν απλό σχεδιασμό διατηρώντας τον κώδικα απλό και βρίσκουν το κουράγιο να συνεχίσουν μετά από κάποια αποτυχία. Το πλαίσιο αυτό συμπληρώνεται με δώδεκα πρακτικές που αλληλεπιδρούν μεταξύ τους και πρέπει να εφαρμόζονται ενιαία σε όλες τις φάσεις της ανάπτυξης. Αυτές είναι:

Ονομάστηκε το παιχνίδι του σχεδιασμού, γιατί ο καθορισμός και η υλοποίηση τόσο των ιστοριών χρήστη, όσο και των εκδόσεων και επαναλήψεων, μοιάζει με παιχνίδι το οποίο διέπουν κανόνες που πρέπει να ακολουθούνται και το οποίο πρέπει να κερδηθεί. Πόσες και ποιες ιστορίες θα υλοποιηθούν σε μία επί μέρους έκδοση, καθώς και το πλήθος των επαναλήψεων της έκδοσης, καθορίζονται σε μία συνάντηση σχεδιασμού έκδοσης (release planning meeting), στην οποία συμμετέχουν όλα τα μέλη της ομάδας και οι πελάτες. Οι ιστορίες, που θα υλοποιηθούν, επιλέγονται από τους πελάτες οι οποίοι επιλέγουν και τους ελέγχους αποδοχής ή ορθότητας του συστήματος (acceptance tests) (βλ. Σχήμα 2). Οι προγραμματιστές εκτιμούν το χρόνο και το κόστος υλοποίησης της κάθε ιστορίας χρήστη. Σε μία επανάληψη μπορούν να αφαιρεθούν ή να προστεθούν ιστορίες ή και επιπλέον διεργασίες ανάλογα με τα χρονικά περιθώρια  και τις δυνατότητες που παρέχονται.
Μέσω αυτής της προσθαφαίρεσης ιστοριών και εργασιών, μπορεί να μετρηθεί η ταχύτητα του έργου (project velocity). Οι ιστορίες χρήστη, αφού περάσουν από τον έλεγχο αποδοχής, προωθούνται στην γραμμή παραγωγής, όπου ανατίθενται υπεύθυνα με υπογραφή σε ζεύγη προγραμματιστών. Η ομάδα δεν εξαναγκάζει τους προγραμμα-τιστές να αναλάβουν την ανάθεση συγκεκριμένων ιστοριών χρήστη. Κάθε προγραμματιστής υπογράφει για τόση δουλειά, όση εκτιμά ότι μπορεί να τελειώσει σε μία επανάληψη. Η εκτίμηση του χρόνου υλοποίησης μιας ιστορίας χρήστη γίνεται συνήθως σύμφωνα με το πλήθος των προγραμματιστικών διεργασιών, που έχουν αποφασιστεί. Οι προγραμματιστές οι οποίοι επίσημα υπογράφουν για την υλοποίηση κάποιων ιστοριών χρήστη, μπορούν να ζητήσουν και να έχουν την βοήθεια άλλων μελών της ομάδας.
Η καθοδηγούμενη από ελέγχους ανάπτυξη (Test Driven Development - TDD) αποτελεί το κέντρο βάρους της ανάπτυξης λογισμικού του ακραίου προγραμματισμού. Αυτή η προσέγγιση έγινε αποδεκτή ακόμη και από τους θιασώτες των παραδοσιακών μεθόδων και υλοποιείται από δύο σημαντικές πρακτικές που ήδη εφαρμόζονται και σαν μεμονωμένες πρακτικές στην βιομηχανία λογισμικού: του προγραμματισμού σε ζεύγη προγραμματιστών και τους ελέγχους πριν την κωδικοποίηση. Προγραμματισμός σε ζεύγη σημαίνει ότι η ομάδα χωρίζεται σε ζεύγη προγραμματιστών και το κάθε ζεύγος αναλαμβάνει την ολοκλήρωση μιας διεργασίας. Κάθε ζεύγος προγραμματιστών χρησιμοποιεί έναν υπολογιστή. Ο ένας προγραμματιστής ο οδηγός (driver) κωδικοποιεί και ο άλλος o πλοηγός (navigator) ελέγχει τον κώδικα συνεχώς για την αποφυγή λαθών και προτείνει λύσεις για την ανάπτυξη. Οι προγραμματιστές αλλάζουν συνεχώς ρόλους αλλά και συνεργάτες, όταν το απαιτούν κάποιες διεργασίες. Τα πλεονεκτήματα του προγραμματισμού σε ζεύγη είναι η ταχύτερη ανάπτυξη του κώδικα και ο περιορισμός των λαθών, που σημαίνει ποιοτικότερο κώδικα. Επιπλέον η συχνή αλλα-γή συνεργάτη βοηθά στη μεταφορά της εμπειρίας και γνώσης σε όλα τα μέλη της ομάδας. Τα πλεονεκτήματα του προγραμματισμού σε ζεύγη καθώς και η σωστή εφαρμογής της πρακτικής αποτελούν θέματα έρευνας τα τελευταία χρόνια. Οι τρόποι ανάπτυξης ποιοτικού λογισμικού με την ορθή χρήση της πρακτικής αποτέλεσε το κύριο θέμα δύο ελεγχόμενων πειραμάτων που υλοποιήσαμε με φοιτητές του Τμήματος Πληροφορικής του Α.Τ.Ε.Ι.Θ.
Οι έλεγχοι του κώδικα είναι συνεχείς, ποιοτικοί και αυτοματοποιημένοι, παρέχοντας μία δικλείδα ασφαλείας σε κατασκευαστές και πελάτες. Πριν από κάθε κομμάτι κώδικα γράφεται πρώτα το αντίστοιχο κομμάτι ελέγχου μονάδας ή ενότητας (unit test) (βλ. Σχήμα 3). Ο κώδικας του ελέγχου μονάδας είναι ο ίδιος με τον παραγόμενο κώδικα, με την διαφορά της προσθήκης των εντολών ελέγχου. Οι έλεγχοι αυτού του τύπου είναι πολλαπλοί, μικρής εμβέλειας και συγκρίνουν τα αναμενόμενα αποτελέσματα με τα πραγματικά. Αποτελούν ένα ρητό μέρος του κώδικα, που διασφαλίζει και τεκμηριώνει τη σωστή λειτουργία του. Η συγγραφή και εκτέλεση των ελέγχων μονάδας γίνεται με γρήγορο και αυτοματοποιημένο τρόπο, συνήθως με την χρήση κάποιου εργαλείου. 

Ένα από αυτά τα εργαλεία, που είναι ανοικτού κώδικα και προσφέρεται δωρεάν, είναι το JUnit (για την Java - με παραλλαγές και για άλλες γλώσσες προγραμματισμού), το οποίο ανέπτυξαν οι Beck και Gamma. Οι έλεγχοι μονάδας κατηγοριοποιούνται και αποθηκεύονται σε κατηγορίες δοκιμών (test suites). Όλα τα μέλη της ομάδας έχουν κοινή πρόσβαση σε αυτούς τους ελέγχους. Κατά την διάρκεια της ανακατασκευής του κώδικα ή της διόρθωσης κάποιου λάθους ξαναεκτελούνται όλοι οι έλεγχοι μονάδας. Μία συγκεκριμένη ομάδα ελέγχων μονάδας ορίζεται σαν έλεγχος περίπτωσης (test case), ενώ κάθε έλεγχος μονάδας ξεκινά με μία κλάση δοκιμής (test class) που καλεί αντίστοιχες μεθόδους δοκιμής (test methods). Συνηθισμένη πρακτική είναι η ανάπτυξη πολλαπλών κλάσεων ελέγχου για κάθε κλάση του συστήματος. Αυτό γίνεται για λόγους τεκμηρίωσης ιδιαίτερα στις περιπτώσεις ανάπτυξης των διεπαφών ή άλλων πολύπλοκων δομών κώδικα. Οι έλεγχοι του συστήματος δεν περιορίζονται μόνο στους ελέγχους μονάδας αλλά συνεχίζονται σε όλες τις φάσεις της ανάπτυξης και περιλαμβάνουν τους ελέγχους ενσωμάτωσης (integration testing), τους λειτουργικούς ελέγχους (functional testing), και τους προαναφερθέντες ελέγχους ορθότητας ή αποδοχής. Για να διατηρήσει η ομάδα ανάπτυξης τον κώδικα απλό και τεκμηριωμένο τον ανακατασκευάζει συχνά ακολουθώντας κάποια σταθερά πρότυπα κωδικοποίησης, που είναι κοινά για τους προγραμματιστές και την εταιρία. Στην περαιτέρω απλοποίηση του τρόπου ανάπτυξης και της κωδικοποίησης συμβάλει και η ακολουθούμενη πρακτική της 'συνολικής εικόνας του συστήματος', η οποία καθορίζει κοινή κωδικοποίηση και ονομασία των κλάσεων, των αντικειμένων αλλά και της όλης αρχιτεκτονικής του συστήματος. Το μεγαλύτερο πλεονέκτημα από τον απλό και κατανοητό κώδικα είναι ότι μπορεί εύκολα να ανταποκριθεί σε νέες απαιτήσεις και επεκτάσεις. Στις περιπτώσεις των αλλαγών και επεκτάσεων το κόστος παραμένει σχεδόν σταθερό καθ' όλη τη διάρκεια του κύκλου ανάπτυξης του συστήματος, σε αντίθεση με τις άλλες μεθόδους.     
Με τις συνεχείς και καθημερινές ενσωματώσεις ή ενοποιήσεις του κώδικα το σύστημα διατηρείται ολοκληρωμένο, παρέχοντας ακόμη και από τα πρώτα στάδια της ανάπτυξης την δυνατότητα της παράδοσης ωφέλιμου λογισμικού σε μικρές εκδόσεις. Η συνεχής ενσωμάτωση του κώδικα βοηθά στο σχηματισμό της τρέχουσας εικόνας του συστήματος σε σχέση με το επιδιωκόμενο τελικό προϊόν και στη μείωση της ασυμβατότητας των διαφορετικών τμημάτων κώδικα των υποομάδων. Κατά την ενσωμάτωση του έτοιμου κώδικα εκτελούνται οι έλεγχοι ενσωμάτωσης για την εύρεση πιθανών σφαλμάτων σε επίπεδο συστήματος. Είναι πιο εύκολη η διόρθωση ενός σφάλματος που προέκυψε την προηγούμενη μέρα παρά η διόρθωση πολλαπλών σφαλμάτων προηγουμένων εβδομάδων.
Ο ακραίος προγραμματισμός δίνει ιδιαίτερη έμφαση στην ομαδική εργασία (Beck, 2000; Cockburn, 2002; Highsmith, 2002). Οι ομάδες ανάπτυξης πέρα από τους προγραμματιστές και τους διευθυντές των έργων συμπεριλαμβάνουν και τον πελάτη / χρήστη που έχει καθημερινή παρουσία στον χώρο παραγωγής. Στόχος της ομάδας είναι η ανάπτυξη ποιοτικού λογισμικού μέσα στα προβλεπόμενα χρονικά διαστήματα για την ικανοποίηση του πελάτη. Ο πελάτης πρέπει να είναι πλήρως καταρτισμένος και ενημερωμένος, ώστε μέσω της διαπροσωπικής επικοινωνίας να βοηθά στην υλοποίηση του συστήματος. Είναι αυτός που καθορίζει την προτεραιότητα εκτέλεσης των ιστοριών, βοηθώντας την ομάδα να προβλέπει με μεγαλύτερη ακρίβεια πόσο έργο μπορεί να παραχθεί σε δοθέν χρονικό διάστημα. Στα καθήκοντα του πελάτη συμπεριλαμβάνεται και ο καθορισμός των ελέγχων αποδοχής για να διασφαλιστεί η σωστή υλοποίηση των ιστοριών. Οι έλεγχοι αυτοί δημιουργούνται από τους πελάτες ή από την ομάδα των προγραμματιστών, ή από κάποιο ανεξάρτητο πρόσωπο.
Οι προγραμματιστές είναι αυτοί που μαθαίνουν να αποδίδουν γρήγορα επιχειρηματική αξία δημιουργώντας ποιοτικό λογισμικό, χτίζοντας μία σχέση εμπιστοσύνης με τον πελάτη. Είναι αυτοί που αναπτύσσουν το λογισμικό σε μικρούς επαναληπτικούς κύκλους, παρέχοντας τακτικά στον πελάτη μικρές εκδόσεις του συστήματος για καλύτερη ανατροφοδότηση. Καθορίζουν την αρχιτεκτονική, σχεδιάζουν τη γενική μορφή του συστήματος και δημιουργούν τους ελέγχους και τον πηγαίο κώδικα. Η σχεδίαση βελτιώνεται σταδιακά μέσω της ανακατασκευής του κώδικα. Καθένας στην ομάδα έχει την δικαιοδοσία να κάνει αλλαγές στον κώδικα, αρκεί να τις κάνει με τον συνεργάτη του, ακολουθώντας τα πρότυπα κώδικα και διασφαλίζοντας ότι όλοι οι έλεγχοι του συστήματος εκτελούνται σωστά. Μέσω της συλλογικής ιδιοκτησίας του κώδικα, του προγραμματισμού σε ζεύγη, της διαπροσωπικής επικοινωνίας και του υποφερτού ρυθμού εργασίας (εργασία μόνο οκτώ ώρες την ημέρα χωρίς υπερωρίες) παράγεται έργο με τους καλύτερους δυνατούς τρόπους και επαυξάνεται η προσωπική ικανοποίηση των προγραμματιστών. Η ανάπτυξη ενός συστήματος μπορεί να διαρκέσει μήνες ή και χρόνια, όμως η καλύτερη ανταμοιβή για τους προγραμματιστές είναι το διαρκές αίσθημα της παραγωγικότητας και ολοκλήρωσης, που δημιουργείται σε κάθε φάση της ανάπτυξης. Η ικανοποίηση των προγραμματιστών είναι μεγάλη όταν μέσα σε λίγα λεπτά εκτελούν με επιτυχία τους ελέγχους μονάδας, όταν μέσα σε λίγες ώρες ενσωματώνουν έτοιμο κώδικα και όταν μέσα σε λίγες εβδομάδες παραδίδουν στον πελάτη κάποια έκδοση του συστήματος.  
Η συνολική εφαρμογή των πρακτικών του ακραίου προγραμματισμού σε μία εταιρία που εφαρμόζει παραδοσιακές μεθοδολογίες ίσως φανεί δύσκολη και απαιτήσει κάποιο χρονικό διάστημα προσαρμογής. Όμως δεν θα πρέπει να εκληφθεί σαν την αναγκαστική ακολουθία μιας λίστας από απαράβατους και δύσκαμπτους κανόνες αλλά σαν μια νέα ενιαία προσέγγιση ανάπτυξης λογισμικού, που πρέπει να ενσωματωθεί με ευελιξία και φυσικότητα στις επικρατούσες συνθήκες και πιθανές ιδιαιτερότητες του εργασιακού μας περιβάλλοντος. Από τις μέχρι τώρα ερευνητικές μελέτες αλλά και από τις εμπειρίες των ανθρώπων της βιομηχανίας λογισμικού, οι οποίες εφαρμόζουν τον ακραίο προγραμματισμό, τα συμπεράσματα είναι εντυπωσιακά. Η φιλοσοφία της καθοδηγούμενης από ελέγχους ανάπτυξης έχει αναγνωριστεί πλέον από όλους σαν την καλύτερη προσέγγιση ανάπτυξης λογισμικού και εφαρμόζεται ανεξάρτητα από την μεθοδολογία που ακολουθείται. Η έμφαση που δίνει στον τρόπο υλοποίησης και αποτίμησης του εκτελέσιμου κώδικα, αποσκοπώντας πάντα στην ανάπτυξη ποιοτικότερου κώδικα και στην ικανοποίηση του πελάτη, κατέστησαν τον ακραίο προγραμματισμό την πιο επιτυχημένη μέθοδο. Παρόλα αυτά υπάρχουν ακόμα πολλές πτυχές των πρακτικών, που πρέπει να διερευνηθούν, ιδιαίτερα ο τρόπος χρήσης εκείνων των πρακτικών που απαιτούν όχι μόνο τεχνολογικές γνώσεις και εμπειρία αλλά και υψηλές προσωπικές ικανότητες και δεξιοτεχνίες. Για όλους αυτούς τους λόγους επικεντρώσαμε την εμπειρική μας έρευνα στις τις νέες αυτές προκλήσεις της μεθόδου, ώστε μέσω τεκμηριωμένων συμπερασμάτων να συμβάλουμε στη διεύρυνση του πεδίου γνώσης και εφαρμογής των μεθόδων αυτών.